Soft-reconfigurable massively parallel architecture and programming system

ABSTRACT

The present disclosure provides a methodology for reducing congestion of a processing unit, preferably by configuring a plurality of functional blocks to run in parallel or in series without the influence or input from the processing unit. In an embodiment, the present method chains a plurality of functional blocks together by software so that one functional block starts after the completion of another functional block. The configuration of the chain can be series, parallel, and any combination thereof, arranged to meet the circuit&#39;s objective. The chaining can be configured and re-configured, preferably by software input. The chaining can also be performed at design time or at run time. The chaining can also be modified, preferably at design time, but can also be modified at run time.

This application claims priority from U.S. provisional patent application Ser. No. 60/974,451, filed on Sep. 22, 2007, entitled “Soft-reconfigurable massively parallel architecture and programming system”; which is incorporated herein by reference. This application is related and co-pending to U.S. patent applications entitled “Soft-reconfigurable massively parallel architecture and programming system”, attorney docket number NAV001A, and NAV002; and to U.S. patent applications entitled “Re-configurable bus fabric for integrated circuit”, attorney docket number NAV003.

FIELD OF THE INVENTION

The present invention relates to apparatuses and methods to integrated circuits, and more particularly to hardware and software system design and parallel processing architecture and programming system.

BACKGROUND OF THE INVENTION

Everywhere in communication systems, increasingly sophisticated algorithms are being used to support higher data rates and richer services. This is true in all application areas, but perhaps most visibly in mobile and video segments, where the move to new generation is driving significant changes in component design for telecoms equipment and Multimedia Video equipment, such as multi stream/channel based real-time video surveillance equipment where intelligent inline/in-situ decisions have to be made. In addition to basic voice and messaging, UMTS paves the way for telecom operators and now WIMAX based open systems, and possibly open spectrum such as 700 MHz in US will offer sophisticated data oriented services that industry analysts predict are essential for revenue growth over the next decade.

As people strive for higher data rates or longer reach over fixed channels, data rates get ever-closer to Shannon's limit and more sophisticated algorithms are required. Indeed, the requirement for signal processing is rising ten to a hundred times faster than Moore's law can deliver.

Estimation and detection algorithms in today's communication systems require the number of operations per second to grow by a factor of ten every four years; that compares to the increase in processor speed from Moore's law of a factor of ten every six years. Worse, while Moore's law holds well for general purpose processors and memory, the difficulty of integrating ever bigger systems means that the growth curve for complex System-on-a-chip (“SoC”)-ASICs is significantly slower—“the design gap”—with a CAGR of 22%.

Not only must equipment deliver improved performance, design times are under pressure and budgets are stressed, often in an environment where standards are shifting. Example WiMax started out in 2001 (IEEE 802.16d) with stationary network based wireless vision, in 2006 transformed into mobile (IEEE 802.16e) and now wanting to transform further by supporting wide spectrum in FDD & TDD domain to provide further spectrally efficient transmission of Data, Video, and Voice (802.16m).

A fundamental change approach is required, and a growing awareness of the attractiveness of reconfigurable DSP, flexible architectures or other (SDR) systems. Makimoto's wave would suggest such a transition is overdue with the most desirable characteristics of these techniques including “efficient”, “optimal” or “cost effective”.

SUMMARY

In an embodiment, the present invention discloses a flexible and reconfigurable architecture for microelectronic processing units. This architecture offers soft-configurability and soft-reconfigurability, using software programming to arrange the circuits' functionality without disturbing the hardware layout, thus providing a general purpose product family to accommodate and optimize a variety of different products. This architecture further offers high performance in the form of massive parallelism and high flexibility where the processing units are soft-arranged to perform different tasks.

In some embodiments the present invention employs configurable building block components to accomplish custom functions and accelerate system design. With soft-reconfigurable building blocks distributed within an integrated circuit, the present system allows the design engineers to develop different applications with minimal effort. The present system further provides a method for building an embedded system where the software configures how the different IC components communicate with each other to achieve the overall objective.

In an embodiment, the present invention discloses a functional component (FC), comprising a functional block (FB) and two control components: a GO component adapted to start the functional block, and a DONE component adapted to identifying the completion of the functional block. The functional block comprises a group of devices for performing a set of logical processing, such as logic design module, a coprocessor, an ALU, a logic design having a plurality of RTL code lines, or an IP block. The control components store multiple electrical states and can be designed to control the functional block, such as starting the functional block and/or storing the status of the functional block.

In an aspect, the start function of the functional block is linked to a state of the GO component, e.g., the GO component can cause the functional block to start processing. For example, the functional block starts when the GO component has an asserted state. The asserted state can actively or passively start the functional block, e.g., by either sending a signal to the functional block, or by the functional block monitoring the state of the GO component and starts when observing an asserted state. There can be one or more GO components, and the functional block can be started independently from one or more sources. For example, if a functional component has two GO components, either GO component can cause the functional block to start executing. The GO components can be linked together by a logical function, and thus the functional block can be started from the completion of one or more sources. For example, two GO components are linked together with an AND function, and thus the functional block will start when both GO components are asserted, such as after two previous functional block provide completion signals to the GO components.

The DONE component can store the status of the functional block, preferably for signaling the completion of the functional block. The GO and DONE components can be combined in a flow control block. The GO and DONE components of different functional components can be chained together, so that when a first functional block completes, its DONE state is asserted, which means an asserted state of the GO component of a second functional block and translates to the start of the second functional block.

The functional block can further comprise a GO_OFF component to signify that it is busy processing. The functional block can ignore the GO component (e.g., start command) when the GO_OFF state is asserted. In an aspect, the start command is an AND logical of the GO and the GO_OFF components, meaning the functional block only starts when there is a GO signal and when the functional block is not busy.

In an embodiment, the control components (GO, DONE, or GO_OFF) are register for storing the state of the control components. The control components can be the address of a register, and the state of the control components are the value of the register. Thus setting the GO register starts the functional block, and completing the functional block sets the DONE register.

In another embodiment, the present invention further discloses a linkage component for linking the GO component of one functional component to the DONE component of another functional component. After configuring the linkage component, when the another functional component completes its processing, its DONE component is asserted. Since the DONE component is linked to the GO component, the GO component is then asserted, which will start the one functional component. In other words, after configuring a linkage component linking the GO component of a first functional component to the DONE component of a second functional component, the first functional component would start after the completion of the second functional component.

The linkage is preferably soft configurable and re-configurable. In an embodiment, the GO and DONE components are registers. The linkage component can be a link between the GO register and the DONE register. An exemplary linkage component would be a register whose address is stored in the GO and DONE registers. In an aspect, the GO and DONE components store the address of the linkage register which hold the value of the electrical state of the GO and DONE components. Thus when the second function component completes processing, it looks up and retrieves the value of the DONE register. Then the register with this address is asserted to signify that the second functional component has completed processing. Since this is also the state of the GO component of the first functional component, the first functional component is then started after the completion of the second functional component.

In an embodiment, the linkage component can be any state device such as a flip flop, a register or a memory device. In an aspect, the linkage component can be selected to be the same memory (or register) for the GO and DONE components. Thus, the assertion of a DONE component automatically provides the assertion of the corresponding GO component. In another aspect, the linkage component can be selected to be the same address of a memory (or register) with the assertion performed on the register specified by the address of the GO or DONE component.

In an embodiment, linking the linkage component can comprise branches. For example, a DONE component can be linked to multiple GO components of multiple other functional components. Thus at the completion of one functional components, multiple other functional components can start. Also, a GO component can be linked to multiple independent DONE components or multiple DONE components connected in a logical function.

The linking can be performed by software, for example, through a processing unit. The linking can be performed at design time, by soft or hard programming. Further, the linking can be performed at run time, changing the original linkage to another linkage configuration.

In an embodiment, a processing unit can be further included to control and access the GO and DONE components, and/or together with the linkage component. The processing unit can also provide the linkage, configuring and re-configuring the connection between various functional components through the setting of their GO and DONE components.

In an embodiment, the DONE component of a functional component is configured to provide an interrupt to a processing unit. For example, the last functional component would need the service of a processing unit after it has completed its processing.

In an embodiment, memory devices can be included to accommodate data passing between the functional components. The functional components can read and write data to memory devices, and the memory data can pass from one location to another location so that the functional components can access it. In a preferred embodiment, to minimize data transfer, the memory can be arranged so that a functional component can write to a memory block that will be accessed by the next functional component. Thus when processing passes to the next functional component, the input data is readily available without any data transfer.

In an embodiment, the present invention discloses an integrated circuit comprises a plurality of functional components and a component control block for soft configuring the functional components. For example, the component control block can partition the functional components into a plurality of slices for parallel processing. The slices can be identical or can be different. The number of slices depends on the functionality and availability of the functional components, typically 256 slices or less, but more is also possible.

Within each slice, the component control block can chain the functional components for serial processing, parallel processing, or any combination thereof. The chaining can be performed by linking the DONE components with the GO components in various logical functions depending of circuit design objectives.

In a preferred embodiment, the present integrated circuit comprises a plurality of functional blocks and a data block storing changeable data and interfacing with a portion of the functional blocks. The data block can comprise memory devices or memory-mapped registers. The data block is capable of starting the functional blocks, and also accepting output from the functional blocks. For example, the data block is interfaced with the functional blocks in a way that a particular data in the data block can cause a particular functional block to begin processing. In an aspect, the particular data location can be linked to the functional block so that when the data changes to a particular value, the functional block senses the proper value and start executing. In another aspect, the functional block monitors the data location and then starts processing when detecting the proper value.

The functional block can write to the data block, signifying that it has completed processing. A linkage can be established between the data location that a functional block writes to when completed processing and the data location that starts a functional block. Thus for storing a particular data in the data block, the functional blocks can be executed in series or in parallel without any external influence, e.g., from a processing unit. Further, by modifying the data in the data block, the configuration of the functional components is changed, and thus the logical functionality of the functional blocks can be changed without changing the physical structures of the functional blocks or the integrated circuit.

The functional block can write to the data block, signifying that it has started processing, and is currently busy. This signal can be used to prevent the functional block from starting when still busy processing. In an aspect, the starting signal to the functional block is a combinatory logical function of the start data and the busy data of the data block.

In an embodiment, the integrated circuit further comprises memory block for input and output, interrupt signal to get the attention of a processing unit, stop signal to stop the operation of the functional blocks, and analysis memory and program to collecting data and analyzing the performance statistics of the functional blocks. The statistics can be used to optimize the configuration of the functional blocks.

In an embodiment, the present invention further discloses methodology for reducing congestion of a processing unit, preferably by configuring a plurality of functional blocks to run in parallel or in series without the influence or input from the processing unit. The method can provide massively parallel architecture, preferably by configuring the functional blocks into a plurality of parallel slices.

In an embodiment, the present invention discloses chaining a plurality of functional components together by software so that at least one functional component starts after the completion of at least another functional component. The chain of functional component can operate without the interaction of the processing unit. At the end of the chain, an interrupt can be raised to get the attention of the processing unit. After chaining, a plurality of functional components can run independent of the processing unit, can only require intervention of the processing unit at the end of the chain. The configuration of the chain can be series, parallel, and any combination thereof, arranged to meet the circuit's objective. A plurality of chains might be configured, for example, for parallel processing, and also for cross data passing between chains.

The chaining can be configured and re-configured, preferably by software input. For example, the chaining can be performed by a processing unit or by register writing. The chaining can also be performed at design time or at run time. The chaining can also be modified, preferably at design time, but can also be modified at run time.

The chaining data and the performance of the functional components according to the chain configuration can be collected for optimization purpose. The data can be analyzed and the analysis can provide optimum configuration, or different functional components in an integrated circuit.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of an exemplary functional component.

FIG. 2 illustrates a schematic of an exemplary functional component.

FIG. 3 illustrates an exemplary connection of functional components.

FIG. 4 illustrates an exemplary chaining methodology for connecting functional components.

FIG. 5 shows a preferred embodiment of a Functional Component.

FIG. 6 illustrates an exemplary flowchart for system operation.

FIG. 7 shows an exemplary chain process for a plurality of functional components.

FIG. 8 illustrates an exemplary configuration of slice arrangement.

FIG. 9 shows an exemplary SOC architecture, comprising a CPU and a functional structure (FS) coprocessor.

FIG. 10 illustrates an exemplary system configuration with a plurality of slices.

FIG. 11 illustrates another exemplary architecture with slices.

FIG. 12 illustrates an exemplary feedback loop to prepare implementations.

FIG. 13 illustrates an exemplary process to mapping applications to existing implementations.

FIG. 14 illustrates an exemplary hardware/software stack according to embodiments of the present invention.

FIG. 15 shows an exemplary floorplan with slices and bands.

FIG. 16 illustrates an exemplary local bus configuration.

FIG. 17 illustrates an exemplary local arbiter configuration.

FIG. 18 illustrates an exemplary embodiment comprising local memory bus and arbiter configuration.

FIG. 19 shows another embodiment of a slice configuration with functional components, memories and arbiters.

FIG. 20 shows an exemplary embodiment of memories and functional component distribution for reducing memory congestion.

FIG. 21 illustrates a slice configuration with memory arbiter and local memory bus.

FIG. 22 illustrates an exemplary arbiter configuration for a plurality of slices and IP block.

FIG. 23 illustrates an embodiment where various functional components are arranged in a slice.

FIG. 24 illustrates an exemplary band configuration for a plurality of slices and IP block.

FIG. 25 shows an exemplary system configuration.

FIG. 26 illustrates an exemplary computer system which can be used in the present invention.

FIG. 27 illustrates a schematic block diagram of a sample computing environment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Acronyms:

ASIC Application Specific Integrated Circuit

CAGR Compound Annual Growth Rate

CCB Component Control Block

CPU Central Processing Unit

DDI Digital Design Implementation

DSP Digital Signal Processing

FB Functional Block

FC Functional Component

FCB Flow Control Block

FDD Frequency Division Duplexing

FFT Fast Fourier Transform Block

FIR Finite Impulse Response Filter Block

FPGA Field-Programmable Gate Array

IC Integrated Circuit

IP Intellectual Property embodied in a circuit

LCCB Local Component Control Block

MIMD Multiple-Instruction, Multiple Data

MISD Multiple Instruction, Single Data

MMU Memory Management Unit

OS Operating System

RDL Register Definition Language

SIMD Single Instruction, Multiple Data

SoC System on a Chip

SDR Software Defined Radio

TDD Time Division Duplexing

TDDM Time Division Demultiplexer

TDM Time Division Multiplexer

UMTS Universal Mobile Telecommunications System

WIMAX Worldwide Interoperability for Microwave Access

In some embodiments, this patent discloses a flexible and reconfigurable architecture for processing units such as processors, microprocessors, controllers and embedded controllers to address the rapid development and shorter cycle of the products. This architecture offers soft-configurability and soft-reconfigurability to accommodate a variety of different product families, together with high performance in the form of massive parallelism and high flexibility where the processing units are soft-programmed to perform different tasks. The present architecture also addresses control congestion by delegating a large number of CPU decisions to its slaves, and addresses memory bus congestion with interspersed local memories. The present architecture relieves the dependency on the CPU for faster execution, providing a new framework for a massively parallel computational system to improve efficiency and performance. In the system, most tasks are to be processed on the independent multiple slice subsystems so that the dependency on CPU decreases significantly.

The present device architecture provides real time signal processing capability with internal reconfigurability suitable for handling high bandwidth digital signal formats such as compressed video, audio, compact disk, digital versatile disc and mixed mode. The architecture of the present system provides DSP inherent high computational processing capability for dynamic video signals with high overall system bandwidth. The system also addresses data processing applications requiring a large number of operations, such as digital signal processing, image processing, pattern recognition, and neural network algorithms.

In some embodiments the present invention comprises a powerful and flexible massively parallel system architecture, a software infrastructure, and the complementing programming and software model. The architecture pertains to IC design, such as using configurable building block functions to accomplish custom functions. In some embodiments specific designs and applications disclosed in this application are implemented on FPGA, especially for DSP (digital signal processing) and image processing. But the present invention has application in many environments such as DSP (digital signal processing), image processing, and other multimedia applications, such as audio and image compression and decompression, code encryption and voice/image recognition, and telecommunications.

The present system provides a flexible computer architecture that in different embodiments is programmed in a wide variety of ways to perform a wide variety of applications. The present system is especially suited to be programmed to function as a parallel processor. The slices are programmed to function as a matrix of processing functional blocks, performing the same operations on different data in parallel. This case allows the present system to operate as a SIMD processor. In some embodiments the slices correspond to different programs, operating as a MIMD or MISD processor. In other embodiments system also operate as a SISD serial processor.

In embodiments the system provides two components to accelerate system design—a highly flexible, reconfigurable architecture, and a design methodology that is compatible with this architecture and maximally utilizes it to achieve huge performance at an affordable price. The present system provides extreme configurability, in that in some embodiments different applications map onto a given design without changing it; low power consumption, in that power optimization abilities are incorporated into the architecture itself, and a methodology that a normal engineering team can pick up and use with minimal effort, for example, to the end-user engineer an implementations of the present architecture are C-language function calls to the peripherals.

The system provides a method for building an embedded system where the software configures how the IC components communicate with each other and with the software, enabling the overall system to perform many different tasks. In some preferred embodiments the IC components perform their individual tasks with little or no involvement by the software.

The present architecture provides reconfigurable mixed analog and digital signal building block functions to accomplish custom functions. This is useful since software is easier to develop, debug, and modify as compare to hardware system design, which is a difficult, time-consuming task with turn-around time and long product cycle. Embodiments of the architecture provide an embedded system with a high flexibility where the software reconfigures the IC components at any time. Thus the present system comprises a hardware implementation that is very flexible and is reused by an entire family of applications. For example, a single embodiment supports a family of DSP applications, while another embodiment supports most image-processing applications.

1. Architecture to Address Control Congestion

In some embodiments a building block for the system is a functional component (FC), comprising a functional block (FB) and a flow control block (FCB). The FB is a group of devices for performing a set of logical processing, such as logic design module, a coprocessor, an ALU, or a logic design having a plurality of RTL code lines. The FCB comprises controllable start and stop functionality for the functional block.

As one example, the FBs contain phase locked loop (PLL) blocks, macro blocks, operational amplifiers, comparators, analog multiplexers, analog switches, voltage/current reference, switched capacitor filters, gm/C filters, data converters, communication blocks, clock generation blocks, customizable input/output blocks, fixed design input/output blocks, and processor blocks.

In some embodiments the FCB starts the FB when the FCB detects a start signal. When the FB completes operation it informs the FCB it has halted. Then the FB halts until the flow control block starts it again. In some embodiments FBs sit adjacent to local memories. Here the FB receives its input from some local memory, and writes its output to other local memory, based on the address where the data is stored. In some embodiments the FCB behaves like a software-controlled switch, to turn on and off the FB.

In some embodiments the FB can be an IP block. The FCB has a done flag, to signify that the functional block has completed its operation. The FCB has a next flag switch, to identify the next FB to activate.

FIG. 1 illustrates an exemplary functional component 10, comprising FB 11 in connection with a FCB 12 through a functional control data path 14. The FB 11 may communicate with other components or devices such as a memory block (not shown) through a data path 13, for example, to transfer data. The FCB 12 communicates with other devices or components through the flow control path 15, to receive external command or to send data.

FIG. 2 shows a FB 20, comprising a FB 21 in connection with a FCB 22. Data is transferred from or to the FB 21 through the data path 23. The FCB 22 sends signal 24A to start the FB 21, and the FB 21 sends signal 24B to identify the completion of the processing. The FCB comprise a GO component 12A and a DONE component 12C. When the GO component 12A is set, e.g. having a value of 1, it starts the FB 21 by sending a start command through the signal path 24A. In some embodiments FCB 22 comprises a GO component 12A that starts FB 21 and thus starts processing when the GO component changes its value. In some embodiments the GO component is an address of a register (or memory) in a Component Control Block (CCB, not shown). When the GO CCB data changes, the FCB recognizes the change and starts processing.

In some embodiments, after the GO command starts its processing, the FB 21 resets the GO component 12A and stops monitoring the GO component 12A until after it finishes processing. In other embodiments the flow control block 22 comprises a GO_OFF component 12B that identifies that the FB is still processing and thus not available for taking a new command.

In some embodiments the GO_OFF component is be an address of a register (or memory) in a Component Control Block (CCB). When the FB 21 starts processing, it changes the GO_OFF CCB data to identify that the FB is busy processing and thus not available. If the GO component is set, it waits until the GO_OFF signal clears before the FB 21 can start processing again.

In some embodiments the FB 21 also resets the DONE component 12C to identify that it has started processing, and set the DONE component when it finishes processing. When the DONE component 12C is set, e.g. having a value of 1, this signifies that the functional component 21 has completed its processing. In some embodiments after complete processing, the FB sends a DONE signal through signal 24B to the FCB 22 to set the DONE component 12C. In some embodiments the DONE component 12C is a memory-mapped register (or memory) in a Component Control Block (CCB). When the DONE CCB data changes, other devices or blocks recognize that the functional block 21 has finished processing.

These particular embodiments are just exemplary embodiments, and skilled persons versed in the art will recognize that there are alternative ways to practice the FCB to control the FB.

In some embodiments the GO, GO_OFF and DONE components include more than one elements linked together in an AND or OR gates. For instance in some embodiments there are be 4 registers for each of the components. In some embodiments the four GO components are connected with an OR gate, in other words there are 4 ways to start the FB 21 by setting each of the GO components. In some embodiments the four GO components are connected with an AND gate, meaning all four GO components have to be set before the FB can start. Here the AND connection provide a synchronization feature, allowing the FB to wait for the four conditions to be satisfied before start processing. In other embodiments the various GO components are connected in various logical fashions, allowing for a variety of scenarios.

In some embodiments the DONE components are more than one registers each. The architecture uses the DONE components to signal the completion of the present FB, which then signals the start of another FB. In some embodiments multiple DONE components allow the chaining of multiple other FBs after the completion of the current one.

Further, in some embodiments the FBs are chained to each other, effectively creating a flow of operation linking multiple FBs. In some embodiments the connections are designed with software at design time, linking the function blocks to perform the desired functionality of the IC chip.

In some embodiments the connections are performed through software, reading through a memory-mapped register interface for connecting together the components of the IC. In such embodiments the software program further specifies how the components of the IC interrupt, and thus change the execution sequence of the software program. Also, the software program specifies how the components of the IC sequence themselves with data passing without any intervention.

FIG. 3 illustrates an exemplary connection of four functional components 31-34, which comprises an FB or IP block. The DONE component of FBs 31 and 33 is chained to the GO component of FCs 33 and 34 through the link 35 and 36 respectively. With this exemplary chain, the completion of FB 31 triggers the start of FC 33, which in turn, after completion, triggers the start of function component 34. Thus in effect, the chaining allows the serial processing of FCs 31, 33 and 34.

FIG. 4 illustrates an exemplary chaining methodology, comprising two FBs 41 and 42, together with a CCB (component control block) 43. The FC 41/42 comprises a FB 41A/42A and a FCB with three registers of GO component 41B/42B, GO_OFF component 41C/42C and DONE component 41D/42D, respectively. The registers 41B-41D and 42B-42D contain the address for the CCB 43, with the corresponding value of 43A-43E.

In some embodiments the FCBs connected to a central processing unit (CPU) for configuring or reconfiguring the address stored in these registers 41B-41D and 42B-42D. These addresses correspond to the registers 43A-43E in the CCB 43. The linking of FC 41 and 42, symbolically illustrated as the linkage 44 between the DONE component 41D and the GO component 42B, is performed by assigning the DONE component 41D and the GO component 42B the same address of the CCB register 43C. In essence, FB 41A finishes processing, it sets the value of the DONE register 41D, which is stored in register 43C. Since this is precisely the value of the GO register 42B, FB 42A thus receives the start signal as soon as the FB 41A finishes. The two FBs 41 and 42 are then chained serially together.

In some embodiments the CPU sets the register 43A of the CCB to start the chain function of FUs 41 and 42. Also, the last DONE component 42D of FC 42 sets the register 43E, which is an interrupt 46 to the CPU. Thus the completion of the chain 41/42 raises an interrupt 43E, which alerts the CPU to take appropriate action.

In some embodiments the CCB is a table of 2^(N) bits, referred to by bit addresses CCB[0:2^(N)-1]. In some embodiments the CCB table is memory-mapped so the CPU is able to view it and to write it. In one aspect, CCB[0] is set to be zero and CCB[1] is 1. CCB[0] and CCB[1] can be hard-wired. A portion of the CCB table, CCB[2:2^(M)-1] with M<N, is reserved as interrupts to the CPU.

FIG. 5 shows an embodiment where the FC has two pieces, an FB, which can be any logic device or IP block, and an FCB. The blocks can have simple memory-mapped register set and also provides interrupts to the CPU. The FCB interacts with the CCB, in an embodiment such as this one through 12 N-bit addresses in the flow control block: 2^(Q) (4 shown) start addresses GO_ADDR_(—)0, GO_ADDR_(—)1, . . . , 2^(R) (4 shown) busy addresses GO_OFF_ADDR_(—)0, GO_OFF_ADDR_(—)1, . . . , and a plurality (1 shown) of completion/chaining addresses DONE_ADDR_(—)0, . . . .

In some aspects, in normal operation of the component, the FC starts the component when the start condition involving a logical function for the start addresses is satisfied. For example, CCB[GO_ADDR_(—)0[N-1:0]]==1. At the time the machine starts, the FCB sets the busy signal in the CCB to indicate the status of the functional block. For example, CCB[GO_OFF_ADDR_(—)0[N-1:0]]==0.

In such as embodiment at the time the machine completes, the FCB sets the completion signal in the CCB, to indicate the completion status and possibly to start the chaining process. For example, CCB[DONE_ADDR_(—)0[N-1:0]]==1. This completion mechanism allows the CPU to chain together a series of predefined components in such a way that they run in series.

In embodiments such as the one described above, the FCB is interlinked with the CCB where the FCB carries the addresses and the CCB carries the value. In some aspects not all CCB bits connect to every FC. The connection is typically determined for a given implementation, where each CCB bits is connected to a particular FC. This prevents needless congestion for the CCB bits. In some embodiments the connection is software driven, meaning the registers of the flow control blocks are set by the CPU following the current program. This mechanism effectively performs the chaining of the various functional components, creating the necessary flow of functions residing in the FCs.

In some embodiments the system starts with the CPU initializes the connections (FIG. 6). This is possible since the flow control blocks are designed to be memory-mapped for the CPU to access. The initialization chains the FCs together in series, parallel, or in any other logical ways. The chaining is performed through the start addresses and the completion addresses. For example, FC A, at completion, starts another FC in series. In some embodiments Component A starts a plurality of other FCs in parallel. In some embodiments an FC starts after receiving the completion signal of another FC; in other embodiments it waits until receiving a plurality of completion signals, arranged in a predetermined logic. For example, FC C is chained from other FCs D and E through AND logic. This chaining determines that FC C only starts after both FCs D and E complete processing. If D completes processing before E, C is still waiting since the AND logic only permits C to start if both start signals are satisfied.

In some embodiments after initialization, the CPU starts the chain process by setting the start signal in the CCB; the CPU does this by writing the CCB's memory-mapped registers. After stating the chain process, the CPU leaves it all alone; conversely the device only interacts with the CPU through its interrupts. The interrupts signify that the chain process is completed and it is time for the CPU to start another chain process. This mechanism significantly reduces CPU congestion, since the demand on CPU time is now only a small fraction compared to the processing time.

In some embodiments, as FIG. 7 illustrates, the chain process includes a TDDM (time division demultiplexer), a FIR, a FFT and a TDM FCs. The FCs are connected so that the TDDM block is chained to the FIR, then to the FFT, and then to the TDM. In some typical operations the TDDM prepares the data and turns on the FIR block. The FIR processes the data and when completed, turns on the FFT. Once the FFT block finishes, it turns on the TDM, and at the TDM completion, dumps the data into a memory and signals the completion to interrupt the CPU.

In some embodiments, the FCs are arranged as a series of slices where the CPU accesses all FCs and the FCs are tied to the CCB, which is a globally shared resource. The slice and CCB configuration allow for a very high level of parallelism in computation. The CCB and the FC soft interconnection is logically a soft interconnection architecture which connects many devices.

In some embodiments the embedded system comprises a family of slices. Here each different slice design in the family contains a different assortment of FCs. In some embodiments library blocks are added to the selected slice to increase the functionality. In some embodiments these standard library blocks are provided independently and separately from the slices, while in others they are not.

In some embodiments each slice executes different instructions on different FCs using different data streams. Here, after each FC has completed its task, it passes the results to the next FC, and waits for the next instruction. Therefore, the FCs are each synchronized to one another and are capable of passing data amongst themselves. In some embodiments once the slice completes processing its data it raises an interrupt to alert the CPU. Each FC has its functionality is configured by software running on the CPU, and the interconnect between the FCs is also configured by the software running on the CPU. So an embodiment can perform many different dedicated functions by configuring and connecting the system, using only those FCs needed for its implementation.

FIG. 8 illustrates a configuration of slice arrangement for some embodiments. The chip, such as an FPGA, is partitioned into a plurality of slices 51-54, accessed through a global bus 56 and connections 57. There is a plurality of FCs in a slice, for example FCs 51A-51F in slice 51. In some embodiments an IP block occupies whole slice, i.e., the slice 54 is an IP block. Alternately in some embodiments an IP block, e.g. 51E, is embedded in a slice, e.g. 51. In some embodiments the IP blocks are disposed separately at optimal locations for maximum performance and density. In some embodiments IP blocks are incorporated into a slice as a FB, implemented similarly to other blocks in a design.

In some embodiments the FCs in a slice are the same. In some embodiments they are different. There is a plurality of different slice types where each slice type has the same FC. In this exemplary embodiment, slice 51 and 52 are the same type with the same FCs, slice 53 is a different type of slice and slice 54 is an IP block. In some preferred embodiments the implementation of functional blocks within a slice, and the distribution of slice types within a chip is analyzed and predetermined to service a family of applications. The contents of a slice and the types of slices in an IC are based on the family of applications. In an exemplary embodiment targeting a DSP-application slice contains input ports, a TDDM (1 stream→N streams), an FIR, an FFT and a TDM, or an IP block Viterbi.

In some embodiments, the FCs in different types of slices are configured in various configurations. In some of these embodiments, the FCs within the same slice type are arranged in a same configuration, effectively for performing parallel processing. In some embodiments when there are not enough slices of the same type, slices of different types are also configured in this same configuration. In some embodiments slices of the same type are configured differently to provide different functionality. There is enough flexibility in configuring the FCs and slices, with a possible limit being the availability of FCs and slices.

The configuration is performed by software. So after the program is loaded into the CPU, the CPU uses an initialization process to configure the FCs and the slices. This soft configurability lets a chip of the present architecture service a whole family of applications.

In some embodiments the slices have a same configuration, allowing parallel processing of the same process, similar to a SIMD computing mechanism. In some embodiments the slices have different configurations, allowing parallel processing of different processes, similar to MIMD computing mechanism. In some embodiments the slices are chained together to provide serial processing, for example, one long chain for SISD mechanism, and many parallel chains for SIMD or MIMD mechanisms. In some embodiments the present architecture provides massive parallelism, with virtual unlimited scalability for highly cost effective expansion.

In a SIMD (single instruction, multiple data stream) computer, all the processors simultaneously execute an identical instruction with different data set. The main processor is tightly coupled to maintain synchronous operation of the various processors while each processor independently operates upon its data stream. In a MIMD (multiple instructions, multiple data stream) computer, the processors are decoupled and execute instructions independent of the other processors, using an instruction memory and program sequencer logic associated with each processor.

The present architecture combines SISD, SIMD and MIMD architectures. Instructions within a slice are sequentially operated. Instructions supplied to different slices having same configuration can all be operated from a single instruction. Instructions supplied to different slices having different configurations can all be operated from multiple instructions. In some embodiments the individual functional blocks and slices are selectively decoupled from the others to perform individual tasks, and to provide the result to the other blocks or main processor.

In some embodiments the architecture provides for 256 slices. The exact number of slices in an embodiment depends on particular implementation, and expansion capability, which allows some flexibility in the underlying logic design without requiring changes to the software, and on how the designer wants to design the connections of the FCs within the slices. The connections are used to form custom circuitry such as configurable mixed-signal functions.

In some embodiments the present architecture provides large flexibility while alleviating a core problem of control congestion. FIG. 9 shows an exemplary flexible SOC architecture, comprising a CPU, a functional structure (FS) coprocessor (including slices of functional components, and component control block (CCB)), together with other peripherals including memory, communication protocol assemblies such as Ethernet or UART components. In some embodiments the FCs include digital logic that contain at least 16 bits of state, and 16 simple gates of logic. Examples of FCs include FIRs, FFTs, Reed Solomon Decoders, and DES encryption/decryption engines. The CCB is a logic component. Every FC communicates the CCB. For an embodiment the designer chooses which FCs to use and their associate memory size based on what functionality they want the system to have. The designers choose how the software interconnects these components also based on this.

In some embodiments he present architecture reduces control congestion by reducing the requirement of CPU interactions. For example, there is a limit to a CPU capability in service a number of slave devices. In a typical system not of this architecture the CPU starts each slave device on its respective task, and when a slave finishes its current task, it raises an interrupt for the CPU to intervene, possibly by starting the slave again on some other task. When the number of slave devices exceeds the capability of the CPU, for example hundreds or thousands of slave devices, then the CPU is strained into servicing all these slave devices, and performance may suffer.

FIG. 10 illustrates an exemplary system configuration, including a CPU 60 controlling a plurality of slices 61-64 through a global bus 66. The slices are connected to a CCB 65, with interrupt signals 67 back to the CPU 60. The number of slave devices are reduced significantly with the slice configuration, and thus congestion to the CPU is reduced accordingly.

In some embodiments, the present architecture relieves this congestion by grouping the number of slave devices into slices, effectively reducing the number of slave devices that the CPU needs to service (FIG. 11). The control of the slices is passed to the CCB, so that data flows from one device, e.g., a functional block, to the next with predetermined control by the CCB and without the CPU intervention. In some embodiments IP blocks are also incorporated within this scheme. In general once a particular device finishes its operation, it informs the CCB that it is complete. Then the CCB turns on the next device in line to process that data. The CCB can also wait until multiple devices are completed before starting another device. The CCB acts autonomously, without the CPU intervening, and therefore capable of reducing control congestion for the CPU.

In exemplary embodiments, the CCB comprises a plurality of sections with each section covering a plurality of slices. For example, the FCs in slice 61 are connected to section 69 in the CCB 65. Also in an aspect, not all CCB bits connect to every FC in a slice. The connection is typically determined for a given implementation, where each CCB bits is connected to a particular FC. The sections can provides interrupts 67 to the CPU, together with local bus 68 for communication between the sections. In an embodiment, each CCB bit is connected to every FC. In a preferred embodiment, the FCs in each slice are connected to a section in the CCB, thus reducing interconnections between the FCs and the CCB bits. The missing connections can be covered by the local bus 68.

2. Implementation Design

The present invention further discloses implementations of functional components and slices for various family of applications. The implementation is chosen to map well with a variety of applications, ensuring enough power and devices in the implementation to meet the needs of the application, well-matched against the application to minimize surplus in die area, memory, and/or clock speeds, and still serve the need at hand, and having the right components for the application. Various metrics could be built into the slice and stored in local memory or output on debug channels. These include, but are not limited to, timestamps, throughput, memory collisions, FC timing and activity.

In some embodiments, a feedback loop is employed using software to analyze how the application fits onto the implementation (FIG. 12). An application is mapped to an existing implementation and available metrics, providing data to an analysis program. The program calculates what FC is used and how often. If the fit is not good enough in some way, this knowledge is used to generate another implementation. For example, the FC that often used can be duplicated and multiplied and the FC that is not used can be reduced or eliminated. The application is then mapped to the new implementation, and the feedback loop continues.

Over time, a library of implementations is built and a software is then used to analyze a given application's needs (FIG. 13). For example, an application is mapped to the available implementation in the library, which can undergo an analysis program to recommend a particular implementation based on those needs.

3. Software Component

The system described here comprises a hardware architecture, a software architecture, a programming model, and a flow methodology.

The hardware architecture typically comprises a CPU, global memory, various analog peripherals, a global memory bus, and a plurality of slices, functional components and component control block. In some embodiments the present architecture includes various analog peripherals, depending on the specific application. For example, some embodiments implementing DSP functionality have A/D's, D/A's and antennas. Some embodiments implementing networking applications will have SER/DES interfaces.

The present architecture is CPU-agnostic with low control congestion. Thus any microprocessor is suitable. Some embodiments have MMUs and others do not. Some embodiments that have an MMU will use it; others will not.

This system significantly reduces control congestion reduction because the CPU does not need to get involved in detail control of individual functional blocks, but only to set up the CCB, the arbiters, and the logical blocks. Once the whole engine is started, the CPU's involvement is minimal.

Ultimately the CPU controls the whole system. At any given time the CPU observes and/or controls any other given component in the system if it is programmed to do so. In some embodiments, however, the CPU delegates a significant portion of control to the CCB. Thus this architecture utilizes distributed control flow to reduce data congestion.

The present system includes a software programming model. On reset the CPU initializes various system components, such as chaining functional components and slices, using register writing. For example, the chaining sets up a string of DSP functions in a sequence. The whole design then waits for data to come in. The system components process the data with no CPU intervention. In some embodiments the system components interrupt the CPU. In some embodiments the CPU queries the system as it runs, for debugging, checking status, and dataflow analysis.

The present invention further discloses a system infrastructure, providing a means of rapidly developing a prototype for an application, a means to analyze a prototype, allowing developers to see easily what can be improved, and advises to developers on the selection of library design implementation given a set of requirements.

After a determination of the logic blocks, the infrastructure model assigns the logic blocks to memory address ranges after checking for conflicts, and generates the register definition files and the API for the other pieces of software to use.

The designers can start with a digital design implementation (DDI) for rapid prototype with functional descriptions. The system has a library of DDI's, together with an expert system to help the users decide which DDI in the library is appropriate for prototyping a given application. The software programming model offers C language API to program, with a register map showing how every register is memory-mapped. At the point the user has defined his application in software on top of the DDI, the model analyzes the utilization of the DDI to determine which pieces are necessary for a final product and which are not. It emits a record of this. The digital designers use this to help them implement the final product. The number of local memories is analyzed and excess memory is removed for the final product.

During runtime, the CCB track the process time of each functional block. This information is used to turn down the clock speeds for each functional block in the final product for power optimization.

FIG. 14 illustrates an exemplary hardware/software stack according to embodiments of the present system. The hardware stack comprises a device stack 70, which includes slices hardware and IP blocks 70A, communication block such as Ethernet hardware 70B, memory mapped Ethernet devices 70C, and global memory 70D. The hardware stack further comprises a system logic 71, which includes a CPU 71B and memory bus and arbiters 71A. On top of the hardware stack is the software stack 72, which comprises a hardware abstraction layer (HAL) 72A, the communication stack which includes the Ethernet stack 72B, the IP stack 72C, the TCP/UDP stack 72D, and the stacks of SNMP, HTTP, TFTP, DHCP 72E, together with the OS stack 72F, and the application software 72G.

The software HAL sits on top of the CPU, the memory, and the hardware, which the CPU accesses as memory-mapped registers. The HAL (Hardware Abstraction Layer) provides an interface layer for higher-layer software to access the slice hardware and other IP blocks. There is also an Ethernet stack for communication, so the device is accessible over Ethernet. Finally depending on the application in question, there may be higher level software that runs on the system.

The software further includes RDL (Register Definition Language), which is a simple language by which registers and their addresses are defined. It provides abstract names to all registers, which are memory-mapped. The input view of RDL is a file that describes each register, plus its mappings. This can replicate multiple instances as different things. One output view of this is the register definition, specifying each register in the design along with its memory map address.

The HAL is a thin layer of abstraction. It allows the higher layers of software to access the registers in the Slices and the IP blocks with some abstraction. It is implemented as a set of C function calls, which the C language calls use the HAL registers to access the functional blocks.

The software can be implemented for optimizing the connections of the FCs. By monitoring the FCs, for example, through a counter in the CCB for the usage of these units, and how often they are on, the characteristics of the connections for the circuit can be determined. Thus from a code stand point, the CCB connections can be changed and the performance measured. Various connections can be analyzed, and the software can determine an optimize set of CCB connections for the FCs with respect to desired performance, such as low power consumption or fast response.

Some embodiments have other peripheral digital devices in the overall system besides the CPU and the FS. To include these in the interface, their register definitions are added for the access registers to the RDL. The regular memory is accessed normally by the CPU, without the need to go through the HAL.

The software architecture is OS-agnostic. However, the hard real-time nature of the applications at hand requires the operating system be hard real-time. And it is desirable the OS have a small memory footprint. Some examples of this include MicroC/OS and eCOS. In some embodiments the OS runs on the CPU for control functions.

The Ethernet stack, IP stack, TCP/UDP stack, and the software above it—the SNMP stack, the HTTP stack, the DHCP stack and the TFTP stack—is a series of software modules to allow communication, which are designed for testing devices. Also, it is useful for a device in the field to be able to communicate by this method. In some embodiments these functions are present. In others these functions are not essential and are removed for cost effectiveness.

The HAL (Hardware Abstraction Layer) is located in the bottom of the programming model. It is a thin layer of abstraction. It allows the higher layers of software to access the registers in the Slices and the IP blocks with some abstraction.

The software is toolchain-agnostic. In some embodiments it uses the GNU tool suite, which includes gcc for compiling, gdb for debugging, and ancillary tools such as the BFD. When the system turns on the system the OS starts a thread. This thread initializes all the components in the system—all the slices, the IP components, the CCB, etc. Once this all happens the system is ready to run. This thread turns off. If the system requires other threads, for instance to monitor the Ethernet and to run the communications stacks, then the OS also starts those threads.

In some embodiments the system includes more software support, such as code to assign memory addresses to all the slices, IP blocks and CCB and software to generate the HAL.

Some embodiments of this system are implemented on a machine or computer readable format, e.g., an appropriately programmed computer, a software program written in any of a variety of programming languages. The software program is written to carry out various functional operations of the present system. Moreover, a machine or computer readable format of the present invention may be embodied in a variety of program storage devices, such as a diskette, a hard disk, a CD, a DVD, a nonvolatile electronic memory, or the like. The software program, known as a simulator, may be run on a variety of devices, e.g. a CPU.

With reference to FIG. 26, an exemplary environment 300 for implementing various aspects of the invention includes a computer 301, comprising a processing unit 331, a system memory 332, and a system bus 330. The processing unit 331 can be any of various available processors, such as single microprocessor, dual microprocessors or other multiprocessor architectures. In various embodiments the system bus 330 is of diverse types of bus structures or architectures, such as 12-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), or Small Computer Systems Interface (SCST).

In some embodiments the system memory 332 includes volatile memory 333 and nonvolatile memory 334. Nonvolatile memory 334 refers to read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 333, refers to random access memory (RAM), synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), or direct Rambus RAM (DRRAM).

Computer 301 also includes storage media 336, such as removable/nonremovable, volatile/nonvolatile disk storage, magnetic disk drive, floppy disk drive, tape drive, Jazz drive, Zip drive, LS-100 drive, flash memory card, memory stick, optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). In some embodiments removable or non-removable interface 335 is used to facilitate connection.

In some embodiments the computer system 301 further includes software to operate in environment 300, such as an operating system 311, system applications 312, program modules 313 and program data 314, which are stored either in system memory 332 or on disk storage 336. In different embodiments various operating systems or combinations of operating systems are used.

In some embodiments input devices 322 are used to enter commands or data, and include a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, sound card, digital camera, digital video camera, web camera, and the like, connected through interface ports 338. Possible interface ports 338 include a serial port, a parallel port, a game port, a universal serial bus (USB), and a 1394 bus. In some embodiments the interface ports 338 also accommodates output devices 321. such as a USB port, to provide input to computer 301 and to output information from computer 301 to an output device 321. Output adapter 339, such as video or sound cards, is provided to connect to some output devices such as monitors, speakers, and printers.

In the exemplary embodiment computer 301 operates in a networked environment with remote computers 324. The remote computers 324, shown with a memory storage device 325, can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 301. embodiments such as this remote computer 324 connect to computer 301 through a network interface 323 and communication connection 337, with wire or wireless connections. In some embodiments network interface 323 are communication networks such as local-area networks (LAN), wide area networks (WAN) or wireless connection networks. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 1202.3, Token Ring/IEEE 1202.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

As an exemplary embodiment FIG. 27 shows a schematic block diagram of a sample computing environment 40 with which the present invention can interact. The system 440 includes a plurality of client systems 441. The system 440 also includes a plurality of servers 443. In such an embodiment the server 443 is used to employ the present invention. The system 440 includes a communication network 445 to facilitate communications between the clients 441 and the servers 443. Client data storage 442, connected to client system 441, can store information locally. Similarly, the server 443 can include server data storages 444.

4. Architecture to Address Memory Congestion

Typically, a parallel processing computer contains a plurality of processors coupled to one another by a data stream bus and an instruction bus. The processors typically share local memory via the data bus.

Global bus is adapted to support data transfer between the slices, the main processor, and I/O controller. The global bus is configured to carry both instructions and data. Memory bus congestion occurs if every time a device needs to read or to write data, it does so on the global memory bus. If dozens or hundreds of devices try to access the global memory bus at the same time, then the bus itself would become the bottleneck.

The present system is different from this. In some embodiments the present architecture has local memories interspersed throughout the IC for reducing memory congestion. When a device attempts to access a memory location in a local area slice, the access goes directly to that local memory and not to the global memory bus.

Thus memory data access is often the bottleneck forcing long stalls on parallel processor systems, mainly due to the sharing registers and buses. In some embodiments memory contention is significantly reduced with the present massively parallel architecture.

In some embodiments, in the IC floorplan, the memories are distributed throughout the chip area, often uniformly. Thus the present slices and bands attempt to exploit this geographic locality. In an embodiment, the IC is built on an underlying geography—or floorplan—of a functional structure where logic is randomly spread throughout the device, and memories are somewhat evenly distributed.

FIG. 15 shows an exemplary floorplan with slices and bands, using slice local memory bus and band local memory bus. Slices are series of functional components interspersed with local memories and run e.g., north to south. When a functional block inside of a slice accesses a memory local to that slice, then that access stays local and does not go out to the system memory bus. This minimizes traffic and thus contention on the global memory bus. Similarly bands are logical constructs that run perpendicular, e.g., east to west. When a functional block inside a band accesses a memory local to that band, then that access stays local and does not go out to the system memory bus.

FIG. 16 illustrates an exemplary configuration, showing global memory buses 81 and 82 and a plurality of memory 83A-C, 84A-C, and 85A-C. To reduce memory congestion, local memories 83A-85C are dispersed throughout the IC area, together with local memory bus 81A, 81B and 82A, 82B. Local memory buses 81A and 81B can run vertically, and connected to global memory bus 81. Local memory buses 82A and 82B can run in another direction, for example, horizontally, and connected to global bus 82.

Thus memory 83A, 83B and 83C can be connected through vertical slice local bus 81A without a need for global memory bus. Similarly, memories 84A-84C and 85A-85C are also connected through vertical local memory bus 81B. Further, memories 83A, 83B, 84A, 84B, 85A and 84B can be connected by horizontal band local memory bus 82A. Similarly, memories 83C, 84C, and 85C are connected by horizontal band local memory bus 82B. Thus the distributed memories are connected with vertical slice local bus (81A or 81B), or horizontal band local bus (82A or 82B). Only when access is outside of the local area, for example, when memory 83A needs access to memory 84C, then global memory bus is used. With proper incorporation of local memories buses, this global memory bus access is significantly reduced, leading to high memory congestion reduction.

Some embodiments address memory congestion with memory arbiters where most data traffic is through the local bus between memory arbiters. The arrangement of local memory arbiters amounts to a small local memory bus, connecting a few of the memories.

Alternatively, in some embodiments, memories can be connected through arbiters. FIG. 17 illustrates an exemplary embodiment of 2 devices 93A and 93B, with 2 local memories 92A and 92B, connected through the local arbiters 91A-91D. Arbiters 91A and 91C are memory arbiter, controlling access to the memory 92A and 92B. Arbiter 91B and 91D are device arbiter, controlling access to the device 93A and 93B. With this configuration, device 93A can access memory 92A through the device arbiter 91B and memory arbiter 91A. Similarly, device 93A can also access memory 92B through arbiters 91B and 91C. With memories dispersed around the device, memory access is routed through the arbiters, thus relieving global memory bus congestion.

Alternately, in some embodiments, local memory bus and arbiter configuration are combined. FIG. 18 illustrates an exemplary embodiment, showing a global memory bus 100, connecting two local memory buses 101A and 101B through two bus arbiters 102A and 102B respectively. In each local memory bus, the device arbiters and the memory arbiters are controlling the device and the memory, respectively, in terms of communication with the local memory buses. With such a configuration, very local communication is made through the arbiter. Local communication is also made through the local memory bus. And communications outside the local area are made with the global memory bus, which can be designed to be a rare occurrence.

FIG. 19 shows another embodiment, illustrating the functional components, memories and arbiters disposed within a slice, and connected to a CCB and outside slice memory bus.

FIG. 20 shows another embodiment of memory configuration for reducing memory congestion. Memories 202A and 202B are alternatively connected to FCs 201A and 201B through, for example, multiplexers 203A and 203B. An exemplary operation can be as followed. FC 201A runs, receiving and generating data from memory 202A through control signal 204 guiding the multiplexers 203A. When FC 201A completes processing, control signal 204 switches, and now FC 201A receives and generates data from memory 202B. In the mean time, FC 201B runs, receiving and generating data from memory 202A. When the FCs complete processing, the control signal switches, causing the FCs to access alternative memory. This configuration can reduce memory congestion, since no memory needs to be transferred. The multiplexer is an exemplary embodiment, and other implementation can be carried out for switching memories between a plurality of FCs. Further, the above example uses two memories and two FCs, but any number of memories and FCs can be used.

4. Architecture to Address Control and Memory Congestion

Some embodiments of the present system combine control congestion reduction with slice architecture and memory congestion reduction with local bus and arbiter configuration. The configuration comprises multiple slice sections, comprising a series of functional components interspersed with local memories. In some aspects, the FC and the local memory each have a dedicated memory arbiter. In such an aspect the FCs and the local memories can be positioned next to each other, thus an FC has access to two local memories on each side by going through the memory arbiter for that memory. Alternatively, in some embodiments the slice contains a slide memory bus, to service the request for data within a slice. The memory arbiter and the slice memory bus free much traffic from the global memory bus, relieving data congestion and contention on the global memory bus.

In some aspects, the processing unit contains IP blocks with dedicated memories and arbiters. Here the arbiter for an IP block is connected to a plurality of slice arbiters to access data from the slices. This configuration provides local memory access, thus improving congestion within the global memory bus. In some embodiments an IP block memory arbiter is also connected to global memory bus.

In some embodiments, the present processing unit contains a Component Control Block (CCB). The CCB enables the chaining a series of predefined functional components, performing the connections between the functional blocks. After proper chaining, when a functional component or IP block finishes its operation, it uses the CCB to start the next functional component or IP block to continue the process, processing its data outputs. In some embodiments a portion of the CCB includes interrupts to the CPU to request CPU assistance, such as the completion of a slice operation. Not all CCB bits need to connect to every FC. The circuit design and implementation determine for a given embodiment and functionality, which CCB bits connect to which particular functional components. This design prevents needless congestion for the CCB.

FIG. 21 illustrates a slice configuration with memory arbiter and local memory bus. A slice comprises a series of local memories and a series of functional components. A local memory bus 113 connects the global memory bus 110 and pass through the slice 112 to the CCB 111. Each functional component has a dedicated memory arbiter. And each local memory has a dedicated memory arbiter. The functional components and the memory components in a slice logically alternate. Within the slice 112, functional components F are interspersed with memories M, and both are connected to the local memory bus through functional and memory arbiter A. If a functional component in a slice tries to access a logically adjacent memory component then its arbiter routes its request directly to the memory arbiter for that memory, rather than going to the memory bus. Otherwise the memory request goes out to the slice memory bus. With this configuration, slice functionality rarely needs to access the global memory bus 110, since the majority of actions and memory access are contained with the slice 112. The CPU has access to all functional components and the memories through the slice memory bus.

In another embodiment, the present processing unit comprises a CPU (central processing unit) which can monitor and control the whole system, including the CCB, the slices, the functional components and the IP blocks. The present architecture allows the CPU to supervise instead of independently control every component at the same time. After setting up the CCB, the memory arbiters and the flow control blocks, the CPU involvement is minimal and does not get involved in the operation of the individual functional components. In an embodiment the operation of the CPU is limited only to the handling of interrupts, or specific operations.

The CPU uses the memory bus, e.g., global and local, to access everything in the system. The CPU memory-maps all the registers in the system. The CPU uses this ability to initialize or reset the system and to query or set the various pieces of the system as the need arises. In some embodiments there are some global memory in the system, depending on the needs of the application at hand. Typically very little global memory is needed. The memory can be ROM, DRAM, SRAM, flash or any combination thereof. In another aspect, the internal memories distributed throughout the slices and the other IP blocks are primarily for local use, and not considered global memory, even though the CPU has access to them through the global memory bus.

In an exemplary embodiment the configuration, shown in FIG. 22, comprises slices, which are series of FCs interspersed with local memories together with slice memory bus and local memory arbiter connections. When components inside of a slice access a physically adjacent memory then that access stays local and does not go out to the system memory bus. This minimizes traffic and thus contention on the global memory bus. Further in this embodiment each slice and IP block has its own memory arbiter. A given IP block is chained to some slices through arbiter connection, providing local arbiter access instead of global memory bus access. In such an embodiment, every slice and IP block has a memory arbiter connected to the global memory bus.

FIG. 23 illustrates an embodiment where various functional components are arranged in a slice. The functional components are configured for a typical DSP application, chaining a series of functionality, starting from an A/D converter, passing to a TDDM block, continuing with FIR, FFT, IP block Viterbi, and finally to the D/A converter. The CCB controls the serial execution, with the local memory passing successively through each neighbor functional block.

Further, in some embodiments the present architecture provides additional bandwidth through the additional band configuration, shown in FIG. 24. This design provides additional bandwidth for the high data flow, reducing flow congestion. For example, in some such embodiments, slices and IP block are connected through band memory bus, in addition to slice memory bus.

FIG. 25 shows an exemplary system configuration, further comprising a CPU for control the functional structure.

While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims. 

1. A method for reducing processing congestion of a processing unit, comprising: configuring a plurality of chainable functional components, the functional component comprising a plurality of logical devices for performing a function; and chaining together the functional components by a software configuration, wherein the chain of functional components is configured so that one functional component starts after the completion of another functional component, and wherein the chain of functional components is capable of operate without the interaction of the processing unit.
 2. A method as in claim 1 wherein chaining the functional components is performed by the processing unit.
 3. A method as in claim 1 wherein chaining the functional components is performed by register writing.
 4. A method as in claim 1 wherein chaining the functional components is performed at design time.
 5. A method as in claim 1 further comprising signaling an interrupt for the attention of the processing unit at the end of the chain of functional components.
 6. A method as in claim 1 further comprising checking the status of the chain of functional components by the processing unit.
 7. A method as in claim 1 further comprising measuring the performance of the individual functional component for optimizing the chain configuration.
 8. A method as in claim 1 further comprising modifying the chain of functional components during run time.
 9. A method as in claim 1 further comprising starting a plurality of chains of functional components for parallel processing.
 10. A method as in claim 1 wherein the functional component comprises a GO component for storing an electrical state, adapted to start the functional component.
 11. A method as in claim 1 wherein the functional component comprises a DONE component for storing an electrical state, adapted to identify the completion of the functional component.
 12. A method as in claim 1 wherein the functional component comprises a group of devices for performing a set of logical processing.
 13. A method as in claim 1 wherein the functional component is selected from a group consisting of a logic module, a processor, a coprocessor, an arithmetic logic unit, a logic design having a plurality of RTL code lines.
 14. A method as in claim 1 further comprising a memory for input and output operation of the functional component.
 15. A method as in claim 1 wherein an electrical state of the GO component starts the functional component.
 16. A method as in claim 1 further comprising a GO_OFF component for identifying that the functional component is busy processing.
 17. A method for reducing processing congestion of a processing unit, comprising: configuring a plurality of chainable functional components, the functional component comprising a plurality of logical devices for performing a function; and modifying a chain of the functional components by a software re-configuration, wherein the chain of functional components is configured so that one functional component starts after the completion of another functional component, and wherein the chain of functional components is capable of operate without the interaction of the processing unit.
 18. A method as in claim 17 wherein modifying the chain is performed by the processing unit.
 19. A method as in claim 17 wherein modifying the chain is performed by register writing.
 20. A method as in claim 17 further comprising modifying the chain of functional components during run time.
 21. A method as in claim 17 wherein the functional component comprises a GO component for storing an electrical state, adapted to start the functional component.
 22. A method as in claim 17 wherein the functional component comprises a DONE component for storing an electrical state, adapted to identify the completion of the functional component.
 23. A method as in claim 17 wherein the functional component comprises a group of devices for performing a set of logical processing.
 24. A method as in claim 17 further comprising a memory for input and output operation of the functional component.
 25. A method as in claim 17 wherein an electrical state of the GO component starts the functional component.
 26. A method as in claim 17 further comprising a GO_OFF component for identifying that the functional component is busy processing.
 27. A method for reducing processing congestion of a processing unit, comprising: configuring a plurality of chainable functional components, the functional component comprising a plurality of logical devices for performing a function, wherein the functional components form a chain so that one functional component starts after the completion of another functional component, and wherein the chain of functional components is capable of operate without the interaction of the processing unit; starting the chain of functional components; and signaling an interrupt for the attention of the processing unit at the end of the chain of functional components.
 28. A method as in claim 27 wherein chaining the functional components is performed at design time.
 29. A method as in claim 27 further comprising checking the status of the chain of functional components by the processing unit.
 30. A method as in claim 27 further comprising measuring the performance of the individual functional component for optimizing the chain configuration.
 31. A method as in claim 27 further comprising modifying the chain of functional components during run time.
 32. A method as in claim 27 further comprising starting a plurality of chains of functional components for parallel processing.
 33. A method as in claim 27 wherein the functional component comprises a GO component for storing an electrical state, adapted to start the functional component.
 34. A method as in claim 27 wherein the functional component comprises a DONE component for storing an electrical state, adapted to identify the completion of the functional component.
 35. A method as in claim 27 wherein the functional component comprises a group of devices for performing a set of logical processing.
 36. A method as in claim 27 further comprising a memory for input and output operation of the functional component.
 37. A method as in claim 27 wherein an electrical state of the GO component starts the functional component.
 38. A method as in claim 27 further comprising a GO_OFF component for identifying that the functional component is busy processing. 